Current means to communicate with a Secure Digital™ (SD) memory card fall into one of two general modes: (1) a lower performance 1-bit SPI protocol or (2) a higher bandwidth 4-bit SD protocol. The former has the advantage of allowing a very simple interface that, depending upon the application, may require no specialized hardware. The latter allows the maximum theoretical bandwidth available from the device, but in typical application scenarios necessitates specialized hardware to support the SD protocol.
The 4-bit SD mode protocol imposes the use of a Cyclic Redundancy Check (CRC) error checking scheme per each data line. This serves primarily to detect transmission errors due to noise and contact bounce induced by the mechanical interconnect between the demountable card and controller. The CRC computation involves four calculations for each block of data passed on the bus. The nature of these calculations views each bus line (there are 4 bus lines) as an independent bit stream.
However, this leads to a conflict with the data mapping approach of a conventional software CRC calculation, which assumes data is represented as a single bit stream packed into bytes or words of memory. The natural in-memory mapping of SD bus data results in an interleaving of the four bus lines as they are read off of the bus. Attempting to map the SD bus data into a conventional CRC calculation therefore requires unpacking each SD bus line's equal order bits from multiple data bytes into a single line-order byte stream.
This unpacking operation is inefficient without the aid of specialized hardware either in the form of a mechanism external to the CPU or in the form of application-specialized processor instructions. Furthermore, in the case of transmitting data on the SD bus, the results of these four calculations have to be reverse-mapped into the SD bus data bit order before they are transmitted onto the SD bus. A conventional CRC generation operation would require excessive processing overhead negating the throughput advantage via the 4-bit bus over bit serial access methods.
Due to the above-described inefficiencies and processing overhead, a software-based approach to access an SD bus memory device in 4-bit wide mode has not been created. One presently-existing alternative is a hardware-based solution to perform the CRC calculation for the 4-bit SD mode. Although performing the required calculation in hardware requires a fairly trivial amount of circuitry, shifting the problem from moving data via a programmatic CPU pushed/pulled model to one where autonomous hardware performs the same introduces substantial system-wide requirements that typically conflict with the goals of cost sensitive applications.
The only presently-existing exclusive software approach operates to communicate to an SD bus memory card in 1-bit SPI mode where software is used to emulate a SPI host controller. Doing so allows use of CRC generation/validation to be disabled in the communication protocol, but introduces the risk of undetected data corruption. More significantly, the 1-bit SPI mode allows only 25% of the theoretical bandwidth possible from 4-bit SD bus mode.
Therefore, a software-based method to access a bus memory device in 4-bit wide mode with the ability to perform an optimized CRC calculation as dictated by the protocol would be beneficial.